With recent official PHP docker images the Zend OPCache extension is
loaded by default. This is causing some test failures as PHP will output
a warning message when the `integration_runner` attempts to load this
extension. As a result any `EXPECT` statements in tests will fail due to
this extra output.

The solution chosen was to use the “-m” option for the `php` and
`php-cgi` binaries to probe if the Zend OPCache module is loaded by
default in the PHP environment. Both binaries are used in testing so the
defaults of both are considered. The value of the integration_runner
command line option `opcache_off` is also noted. When a test is going to
be run this information is used to determine if the
`zend_extension=opcache.so` is needed as well as setting the values of
`opcache.enable` and `opcache.enable_cli`. These INI values needed
special handling because it is possible these are overwritten by values
in the INI stanza of a given test case. Also consideration is needed to
if the `PHPMODULES` stanza exists in the test case and specifies loading
the `opcache.so` module.

---------

Co-authored-by: Michal Nowacki <[email protected]>

Addresses #1099
Enhances #1100

When Composer runtime API is used to get packages information, the
agent should not generate packages information using legacy methods.
This solves the problem of package data detected with the help of
Composer's runtime API not to be sent to the backend in environments
using “once-per-process” setting. The reason for is that the first 
request generates package information using Composer's runtime API
but every next request only generates package information using legacy
method. This in conjunction with the fact that daemon is only sending
the last package information received from the daemon leads to a
situation that package information returned by Composer runtime API
is lost and never makes it to the backend.